Ian & Stuart's Australian Mac: Not for Sale/Another.not.for.sale (Australia).iso/hold me in your arms/Nexus/nexus.software/magic.money

Internet Message Format | 1994-05-22 | 14KB

From: Sameer <[e-mail]>
Subject: Magic Money and NexBucks
To: [e-mail], [e-mail]
Date: Sat, 14 May 1994 05:01:25 -0700 (PDT)

    I have just now installed the Magic Money digital cash server
on infiniy.hip (it will be called infinity.c2.org once the tlg link
goes up), as the Nexus MagicBank <[e-mail]>.
    The bank issues coins in denominations from 2^0, 2^1, up to 2^12.

    I think a good way to manage the money supply would be to
create a coin of value 2^12 when a new nexus is created and give that
coin to the nexus, for distribution as the nexus sees fit-- hopefully
to those people who have worked hard to make the nexus happen.

    The money supply can grow slowly as the number of nexi in
existance grows..

    Hopefully a setup like this will keep the money supply small
enough so that the Magic Money tokens have some actual value, yet
large enough so that there is enough money to go around. I'm including
the documentation to magic money. To send requests to the server mail
[e-mail] (it will be [e-mail] soon)
and then the server's output will be mailed back to you.
    (No nexi are up yet, so the money supply is nil though. [well
except for '1', which I minted as a test.])

    What do people think of the scheme?

--

You will also need these files from the PGP Tools library, which should
be available from csn.org or wherever you downloaded this.

FIFO.H          FIFO.C          IDEA.C          IDEA.H          MD5.H
MD5.C           MPILIB.H        MPILIB.C        PGPARMOR.H      PGPARMOR.C
PGPKGEN.C       PGPKGEN.H       PGPKMGT.H       PGPKMGT.C       PGPMEM.H
PGPMEM.C        PGPTOOLS.C      PGPTOOLS.H      PLATFORM.H      SYSTEM.H
USUALS.H

Magic Money Digital Cash System
Brought To You By Pr0duct Cypher
Based on PGP Tools - The Crypto Construction Set

Magic Money is a digital cash system designed for use over electronic mail.
The system is online and untraceable. Online means that each transaction
involves an exchange with a server, to prevent double-spending. Untraceable
means that it is impossible for anyone to trace transactions, or to match
a withdrawal with a deposit, or to match two coins in any way.

The system consists of two modules, the server and the client. Magic Money
uses the PGP ascii-armored message format for all communication between the
server and client. All traffic is encrypted, and messages from the server
to the client are signed. Untraceability is provided by a Chaum-style blind
signature. Note that the blind signature is patented, as is RSA. Using it
for experimental purposes only shouldn't get you in trouble.

Digicash is represented by discrete coins, the denominations of which are
chosen by the server operator. Coins are RSA-signed, with a different e/d
pair for each denomination. The server does not store any money. All coins
are stored by the client module. The server accepts old coins and blind-
signs new coins, and checks off the old ones on a spent list.

Suppose Alice wants to pay Bob some Magic Money. Alice uses her client
module to extract some coins from her account (file). She then mails those
coins to Bob, using a secure channel such as a PGP message. Bob runs his
client module on the coins. The client module checks the signatures, and
totals up the value of the coins.

It then prompts Bob to choose the values of new coins which total the same
value as the old ones. For example, Alice sends Bob a 64-unit coin. Bob
chooses a 32-unit and two 16-unit coins. The client module then generates
proto-coins, which are blinded but unsigned. It produces an output file
containing Alice's coins, and the new proto-coins.

Bob mails this to the server. The server counts up Alice's coins, checks
their signatures, and checks for double-spending. It puts the coins on the
cancelled list, signs the proto-coins, and mails them back to Bob. Bob runs
his client module on the reply message. It unblinds the signed coins and
adds them to his coin file. This completes the transfer.

The Magic Money server is a filter, accepting input from stdin and sending
output to stdout. To set up a server, you first compile the server program
and install it in its own directory. Dump some random junk in a file called
rand.dat. This and the system clock is hashed to generate random numbers.

Then execute "s i" to initialize the server. It will prompt you for some
information. For the denominations, I would use powers of 2 (1, 2, 4, 8,
16, 32, 64, 128...) because they minimize the number of coins needed to
transfer any amount. The server will create a key and an e/d list. An
ascii-armored copy of the server's public key is written to bank.asc. Users
must have this key to use the server, so however you publicize your server,
include the key.

Set up the system so that, when a message comes in, the server is executed
and the message (which need not be cleaned up first) is piped into stdin.
The output from the server should be mailed back to the user. The server
can be run through a remailer, if you don't want to reveal your location.
This would be easiest through a penet-style remailer. Operating through a
cypherpunks-style remailer would require an external mechanism to handle
reply headers. However you do it, just see to it that messages go into the
server and the output goes back to the right user.

If you just want to experiment on one machine, put the server and client in
different directories, to prevent their files from interfering with each
other. Set up a shell script/batch file to feed the client's output into
the server and return the server's reply.

The server has the ability to include a message to the client. If the file
msg.txt exists in the server's directory, it will be included in the
server's replies, and the clients will display it. The client will wait for
a keypress after displaying the message, so the last line should be "press
any key to continue" or something similar. The message should not be longer
than one screen, because there is no "more" in the client. The main use for
the message is to warn users of expirations (see below), but you can send
anything you want.

To set up a client, compile the client module (unless the server operator
was nice enough to provide a binary [hint]) and put it in its own
directory. Put some random junk (for random numbers) into rand.dat, and put
the server's ascii-armored key in bank.asc. Now execute "c -i" to
initialize your client. It will create a key and generate "output.asc"
which should be mailed to the server. When the reply comes back, save it
in a file and run "c <file>". This will initialize your e-list and coin
name files. If the server has a msg.txt, you will see it.

Now get another user to send you some coins. Coins are binary, not ascii-
armored, because we assume you will use a PGP message or other "envelope"
to transport them. Execute "c <file>" to process your coins. The client
will show the denominations as the signatures are checked. It will show the
total, and allow you to choose denominations for the new coins you want to
generate. Then it will generate a file "output.asc" which should be mailed
to the server. Take the server's reply and run "c <file>" on it. It will
extract and unblind the coins, displaying them as it does so. When it is
done, you will have some coins to spend.

To pay someone some coins, execute "c -p". The client will show a list of
coins you have, and allow you to choose values to extract. These will be
copied into "coins.dat", which you then mail to the person you want to pay.
He does as above to deposit them. Do not lose "coins.dat" because the coins
are removed from your file as they are extracted.

Server maintenance and expirations: the server must keep track of all the
coins which have ever been spent, at 16 bytes each. While the server uses
an efficient hash file to maintain speed, the file will eventually grow to
consume the entire filesystem of the host machine. There must be a way to
clear it out eventually.

The server operator executes "s n" to generate a new e/d list. The old list
will be renamed. Old coins are still valid at this point. The server
operator should put up a message warning users to exchange their old coins.
The next time a user interacts with the server, his elist will be updated
automatically, and the old one renamed.

The user can (and should be warned to) execute "c -x" to automatically
exchange all his old coins for new ones. After a reasonable time, and
plenty of warning (!) the server operator executes "s d" to delete the old
spent list, efile, and dfile. Old coins are now worthless. The next time
a user interacts with the server, his old elist will be deleted
automatically by his client. Old coins will now show up as having zero
value, and a "c -x" will discard them as "expired coins". If the user was
dumb enough not to exchange his coins, too bad.

The server will only sign as much value as it receives, so the amount of
money in circulation remains constant. We have a chicken-and-egg problem:
how is value created? The server operator has the magical ability to create
new coins from thin air. He executes "s m <x> <x> <x>" where x is the
denomination of the coins he wants. The result is a coins.dat file, which
can be mailed to a user and processed by his client module. The server just
signs the coins directly, without any blinding.

Coins are represented by RSA integers in the normal PGP-signature format.
The coin is 16 bytes, padded in the same way that PGP 2.3a pads a
signature. The coin is stored signed, that is, raised to the d power. There
is no hashing involved; RSA is used directly.

To blind a coin, the client generates a blinding factor, a large random
number. The random number is raised to the appropriate e power, modulo the
server's n. It is then multiplied with the unsigned coin, generating a
blinded "proto-coin", which is sent to the server. The server signs the
blinded coin by raising to the power d. This "decrypts" the blinding factor
at the same time as it signs the coin, because RSA is multiplicative. Then
the client divides out the blinding factor, leaving the signed coin.

How big should the blinding factor be? I am not sure. Right now, it is set
to the modulus minus one byte. This is certainly secure, but it takes a
long time to unblind because mp_inv is a slow operation. If you know how
long it needs to be, feel free to change it.

Now, if you're still awake, comes the fun part: how do you introduce real
value into your digicash system? How, for that matter, do you even get
people to play with it?

What makes gold valuable? It has some useful properties: it is a good
conductor, is resistant to corrosion and chemicals, etc. But those have
only recently become important. Why has gold been valuable for thousands
of years? It's pretty, it's shiny, and most importantly, it is scarce.

Digicash is pretty and shiny. People have been talking about it for years,
but few have actually used it. You can make your cash more interesting by
giving your server a provocative name. Running it through a remailer could
give it an 'underground' feel, which would attract people.

Your digicash should be scarce. Don't give it away in large quantities. Get
some people to play with your server, passing coins back and forth. Have
a contest - the first person who (breaks this code, answers this question,
etc.) wins some digital money. Once people start getting interested, your
digital money will be in demand. Make sure demand always exceeds supply.

If some people get servers up and running, and if there is any interest,
I can write an automatic client which will accept and pay out Magic Money
without human intervention. Please let me know if you have an application
for this, or any other ideas for the system.

                                              Pr0duct Cypher

From: [e-mail] (Sparky)
Subject: Re: Magic Money and NexBucks
To: [e-mail] (Sameer)
Date: Sun, 15 May 1994 02:00:43 +0100 (BST)
Cc: [e-mail] (Nexus Gaia)
In-Reply-To: <[e-mail]> from "Sameer" at
  May 14, 94 02:24:48 pm

    Ive thought and Im back. As Dave says the credits have to have worth,
I can provide that by making them equivalent to online time. Its easy
to imagine a currency building up as people sell virtual items and services
in return for online time and I can give people wages for putting work into
the system maintaining things.
    It would be really nice to interface this into the MUD. The potential
for virtual gadget shops etc is there. Ive been thinking how to do it and
it would be easy to set up a virtual bank in the MUD to buy credits, but
transferring them into the MUD will be tricky. I can't see a way for the
MUD to transfer the money across from the ecafe (its on a seperate system)
when they login. I don't want people to have their credits split over
two systems it'll confuse people terribly.
    At this stage its getting to the point where I ask 'am I breaking
the law'. Am I effectivly printing my own currency? I can effectivly get
something for nothing out of this deal. I can employ a kid to help out in
the Cafe when it gets busy and pay him in virtual credits, which are worth
something to him but only worth something to me if he gets the last terminal
in the place.
    When you get the system running Sameer drop me a line and I'll
patch a HTML interface onto the front. The MUD stuff will be tricker - theres
a whole load of problems which make it very tricky.

-Mark
--
_   /\/|  _   _   /  _  Email:  [e-mail]        IRC: Brandoch
   /   |_( /_/ '_/7     SnailMail: 363 Kings College, Cambridge, England
Mark Cheverton     \_)  Battle PBeM: finger [e-mail]
Electronic Cafe: http://www.cp.tn.tudelft.nl/~battle/mark/ecafe/ecafe.html